Skip to main content

Related RFC Template

Properties of shaped work:

Problem

Begin with a description of the problem (book ref).

Important information to include in the problem description includes: 

  • Impact to customers (if any)
  • Impact to business 
  • Significant potential opportunity or risk

Excerpt:   _The raw idea, a use case, or something we’ve seen that motivates us to work on this ... _ The best problem definition consists of a single specific story that shows why the status quo doesn’t work.

Business Priority (Big 3, Lil 3 or Fab 3)

  • High Level Prioritization Category:  Which of the high level objective is this pitch related to?  (reference)
  • Impediment Theme:  Which of the developer impediments is this pitch related to if any? (reference)

Appetite 

How much time should we be willing to spend on this effort?  2 weeks to 6 weeks are the bounds of any estimate.  These constraints promote tightly scoped, focused, and well-designed solutions. (book ref

The proposal will also need to address the following questions: 

  • What skillsets or expertise will this project require?
  • How many engineers will need to be involved?
  • If embedding on another team, what collaboration model would be ideal (Collaboration, X-As-Service, Facilitation)?  (web ref)

Excerpt:  How much time we want to spend and how that constrains the solution ... Anybody can suggest expensive and complicated solutions. It takes work and design insight to get to a simple idea that fits in a small time box.

Solution

Solutions are meant to be a high-level description of the approach.  Solutions are not meant to be an exhaustive design document.  That said, the solve should contain enough detail for stakeholders to understand the solution concept (book ref).  

Visuals are very helpful in communicating your idea, though they need to remain high-level.  Avoid high-fidelity details and design mocks, that can over-constrain how the solution is eventually implemented.  The following artifacts may help in communicating the solution:

  • Simplified architectural and/or component diagrams
  • Annotated screenshots if the solution will surface in our existing product UX/UI
  • Fat Marker (book ref) sketches if the solution will result in brand-new UX/UI 

ExcerptThe core elements we came up with, presented in a form that’s easy for people to immediately understand ... A problem without a solution is unshaped work. Giving it to a team means pushing research and exploration down to the wrong level, where the skillsets, time limit, and risk profile (thin vs. heavy tailed) are all misaligned.

Outcome

If the project is successful, how will we know?  Consider questions like these:

  • How will this project improve the business and/or our work processes?

  • How will we measure the desired positive impacts of the solution?

  • What potential negative consequences exist? All solutions involve trade-offs; what are the trade-offs we are making here?

Rabbit Holes

Are there any gaps or unanswered questions in the solution which should be addressed prior to starting?  For example:

  • Does this require new technical work we’ve never done before?
  • Are we making assumptions about how the parts fit together?
  • Are we assuming a design solution exists that we couldn’t come up with ourselves?
  • Is there a hard decision we should settle in advance so it doesn’t trip up the team?

This section is a great way to call out potential problems that are not critical so we don't get hung up on them (book ref / rabbit holes concept).

Excerpt :   Details about the solution worth calling out to avoid problems.

No Gos

What is out of scope for this effort?  List these no-gos from the start, and document any others that are discovered during the pitch review process.

Excerpt :   Anything specifically excluded from the concept: functionality or use cases we intentionally aren’t covering to fit the appetite or make the problem tractable.

Longterm Support Model

How will this project or library be maintained moving forward? Will it be handed off to another team for maintenance or will it be maintained within Tech Enablers? 

Sponsor

Is there a specific person who is responsible for supporting the adoption of the work that gets done in this pitch?

We want to make sure we not only create cool new stuff, but also drive the adoption across all organization apps whenever possible, for better consistency. Having a designated Sponsor should help to ensure this.